Some comments:

1. Reduce coverage is narrower in #36648 than in #36644

render_reduce_plan dispatches over six variants. Each one builds its own batcher-backed arrangement(s):

#36644 hooks the bucket call at the top of render_reduce itself, on key_val_input.as_collection(). The bucketed key_val_collection then flows into every variant via render_reduce_plan — one bucket op per Reduce LIR node, all six variants covered.

This matters for the user's repro, which contains — on top of temporal-filter-bearing inputs — a non-monotonic MAX(...) with retractions (→ Reduce::Hierarchical::Bucketed), a window function (lead() → Reduce::Basic), and Accumulable aggregates elsewhere in the pipeline.

If #36648 lands and #36644 is dropped, none of those Reduce sites get bucketing. Cleanest fix: pull the top-of-render_reduce site from #36644 into #36648 and drop the inside-build_monotonic one (the upstream site dominates — by the time data reaches consolidate_named_if, the future-stamped updates have already been held back by the bucket op). Alternative if you'd rather stay site-by-site: add bucket_for_consolidate in build_basic_aggregate, build_accumulable, build_bucketed_negated_output, and build_distinct too.

2. TopK::Basic (non-monotonic) is uncovered

The LIR field PlanNode::TopK::input_strategy is already plumbed by your PR, but only the MonotonicTopKPlan and MonotonicTop1Plan arms of render_topk consult it. BasicTopKPlan (the LIMIT n path with n > 1) goes through build_topk → build_topk_stage → build_topk_negated_stage (top_k.rs L514), which builds its primary arrangement via batcher-backed input.mz_arrange::<…, RowRowBatcher, …>(…). Same future-update pathology, same fix shape.

This is a pre-existing gap (fec2af8-era), not something your PR introduces, but trivial to close while you're in the area: either consult input_strategy in the Basic arm too, or hoist bucket_for_consolidate once above the TopKPlan match.

Triggering shape: SELECT … FROM t WHERE mz_now() < … ORDER BY … LIMIT n with n > 1.

Some more comments, pointing out some differences between #36644 and this PR, in case we want to move forward with this PR.

3. Threshold is not covered

MirRelationExpr::Threshold lowering in #36648 doesn't consult or propagate
the future-updates flag, and render_threshold doesn't bucket. #36644 clears
has_future_updates on Threshold when its conditional new_arranged wrap
fires, as defense-in-depth. (We verified this case is currently unreachable
from any SQL surface because EXCEPT inserts Distinct per leg and
EXCEPT ALL is absorbed by the consolidating-Union per-leg bucketing — see
temporal_bucketing.slt — but having the flag-clear in place protects against
future MIR producers of Threshold.)

4. The Union bucketing decision is split between LIR and render

#36644 folds refine_union_negate_consolidation's consolidate_output = true
decision into the Union arm of lowering, so the per-input
temporal_bucketing_strategies and consolidate_output are decided in the
same place from the same predicate. #36648 keeps the post-pass and has the
render arm combine input_strategies with consolidate_output to decide
whether a bucket op fires per leg.

This is correct, but architecturally unfortunate:

• EXPLAIN PHYSICAL PLAN's
  input_strategies no longer reflects "where bucketing actually fires" —
  render does the final combination, so EXPLAIN won't show the effect of any
  future change in how the two fields are combined;
• it introduces an
  optimization decision at render time, which we'd like to generally avoid.

Easiest near-term fix: fold the predicate into lowering as #36644 does,
deciding both fields together. A longer-term cleanup would be to keep
refine_union_negate_consolidation as a post-pass (post-pass adjustment of
consolidate_output is fine on its own) and add a sibling LIR post-pass that
recomputes the per-input bucketing strategies after the consolidation
decision is finalized — so the bucketing decision is also fully settled in
LIR before render runs.

5. ArrangeBy raw-only wraps

#36644 has a precursor commit that passes false instead of the upstream
future flag at the three synthetic arrange_by(..., new_raw(), ...) sites in
lowering (TopK permute, Negate permute, Union per-input permute),
because a raw-only ArrangeBy builds no arrangement and ensure_collections
forces Direct for raw-only paths anyway. Without that, the LIR records
strategy = TemporalBucketing on ArrangeBy nodes that physically cannot
bucket — misleading in EXPLAIN and a footgun for any future flag-propagation
analysis that reads the LIR. #36648 does not have this fix.

6. MonotonicTop1/K { must_consolidate: false } overhead

#36648 gates the bucket call on must_consolidate (good — avoids the overhead
of a bucket op with no downstream consolidator). #36644 takes a slightly
different angle: it argues (and documents with a soft_assert_or_log! at the
top of render_topk) that the combination "MonotonicTop1/MonotonicTopK
with must_consolidate = false together with TemporalBucketing" is
structurally impossible, because RelaxMustConsolidate (the only writer of
must_consolidate = false) runs only on single-time dataflows, and in
single-time dataflows ExprPrepOneShot constant-folds mz_now() to the
dataflow as_of before lowering — so has_future_updates is false
everywhere and lowering never picks TemporalBucketing to begin with.

Both PRs are functionally correct on this point, but #36648's
runtime gate vs. #36644's invariant + assert are different choices. #36648's
runtime gate is a rendering-time optimization decision, which we'd like to
generally avoid.

7. Default-format EXPLAIN

#36644 adds a Temporally-Bucketed prefix to the default-format physical-plan
printer for Reduce, TopK, and Union, mirroring the existing
Consolidating treatment. #36648 only updates the verbose-text printer.
Nice-to-have for debuggability of the feature.

8. Test coverage